A network data storage controller (“storage controller”) is a physical computing device that is used to store and retrieve data on behalf of one or more other computing devices (“hosts”) that are interconnected with the storage controller via a data communications network, e.g., an intranet or the Internet. A storage controller can be configured (e.g., by hardwiring, software, firmware, or any combination thereof) to operate as a storage server that serves one or more clients on a network, to store and manage data in a set of mass storage devices, e.g., magnetic or optical storage-based disks, solid state storage devices, tapes, etc. Some storage servers are designed to service file-level requests from hosts, as is commonly the case with file servers used in a network attached storage (NAS) environment. Other storage servers are designed to service block-level requests from hosts, as with storage servers used in a storage area network (SAN) environment. Still other storage servers are capable of servicing both file-level requests and block-level requests, as is the case with certain storage servers made by NetApp®, Inc. of Sunnyvale, Calif., employing the Data ONTAP® storage operating system. Two or more such storage servers (“nodes”) are typically connected to form a storage “cluster.” Storage server nodes and clusters are generally configured for use in data centers operated by or for enterprises, e.g., to store application data, configuration data, virtual machine files, etc. (collectively, “data”).
Although addition of storage server nodes and/or clusters enable storage of massive amounts of data, enterprises are also increasingly relying on “cloud data storage service providers” to store data outside their data centers, e.g., for disaster recovery, reduced operating costs, reduced capital expenditures, reduced latencies in regions remote from their data centers, etc. Examples of cloud data storage service providers are Amazon® Simple Storage Service (“S3”), Microsoft® Azure®, Rackspace®, etc.
The various cloud data storage providers can charge different rates for different data storage services, e.g., depending on location, capacity, availability, throughput, volume, and other such service level objectives (“SLOs”). The cloud data storage providers commonly even charge different rates for similar data storage services. Enterprises and other consumers of cloud data storage providers thus sometimes desire to minimize their data storage expenses by moving data from their data centers to cloud data service providers and/or between cloud data storage providers. However, when they move their data, they must reconfigure their applications or systems that use this data and/or their network communications devices because the location (e.g., Internet Protocol (“IP”) address) of the data is now different. Sometimes, even after applications and/or network communications devices are reconfigured, the applications may nevertheless still be unable to locate the data, e.g., because of network address collisions or other network communications errors. Sometimes, enterprises may need to make the data available from different cloud service providers concurrently, e.g., to reduce latencies by causing data to be stored proximate to the hosts that will access the data.
In the classless inter-domain routing (“CIDR”) standard that is generally in use today in Internet Protocol (“IP”) data communications, IP addresses are described as consisting of two groups of bits: the most significant bits are a network address that identifies a network or subnet “routing prefix,” and the least significant bits form host identifiers that specify a particular interface of a host on that network. CIDR notation is a syntax for specifying IP addresses and their associated routing prefix. It appends a slash character to the routing prefix address and the decimal number of leading bits of the routing prefix address, e.g., 192.168.2.0/24 for IPv4, and 2001:db8::/32 for IPv6. This scheme enables multiple hosts to have the same IP address as long as the hosts are on different subnets. For example, two home users can commonly have conflicting IP addresses, 192.168.1.1, yet still send and receive IP packets because they are in different subnets. Similarly, some enterprises may have conflicting ranges of IP addresses that they use internally. These conflicting ranges of IP addresses can make it difficult for enterprises to move their data to cloud service providers without fear of network collisions that could cause data corruption and other issues. For example, when two enterprises (or other users) both become “tenants” in a cloud service provider's infrastructure (e.g., store data), they may both attempt to access data located at the conflicting IP addresses. Cloud service providers generally prevent such conflicting use, thereby causing some applications to fail.